WSL1 再入門
https://3.bp.blogspot.com/-_Re_sidWrNQ/WsiR9hhD4aI/AAAAAAABLJo/wotMY7MI9GIdVDcB1ukXN7w2O88rquRvACLcBGAs/s400/ondanka_animal_penguin.png
WSL2 が 2020 Q1中にリリースされるけど、Insider Preview をわざわざ入れるのもあれなので正式リリース後に変換してやることを想定して改めて入門しておくなど。普段業務だと macOS で作業するので、Homebrew でアレコレすればなんとなーく環境ができあがるのでエコシステム強いなと思った。では始めよう。 WSL を準備する
VSCode を準備する
WSL1 を快適に使おうとするならよほど気に入ってるターミナルがなければ Visual Studio Code についてる TERMINAL を使うのが一番ラク。後述するが VSCode の拡張機能である Remote WSL と連携すると、何も考えずに作業に入れるから。 VSCode の拡張 Remote WSL を入れる
Microsoft の公式拡張である Remote WSL を導入する。Docker とかとも連携できる Remote Container とかのシリーズの一つで、WSL環境をリモート環境と見てVSCodeをフルに連携してシームレスに利用できるようになる。 インストールが正常にできていれば Ubuntu の WSL を自動で検知してくれる。
以降は VSCode を WSL と連携した状態でターミナルを操作、もしくは VSCode から直接ファイルを触る。
.bash_profile を使えるようにする
という表現が正しいかわからないがこのようにしておく。
WSL1 環境下ではシェルのとり方が特殊な仕様なので .bash_profile をおいてるだけではこのファイルをロードしてくれない。.bashrc はとりあえず読んでくれるので .bash_profile があったら使ってくれるようにトラップしておくと良い。
code:bash
echo -e '\n# .bash_profile\ntest -f "$HOME/.bash_profile" && source "$HOME/.bash_profile" || true' >> .bashrc
Homebrew をいれる
code:bash
インストール後はパスを通して brew でインストールしたプログラムを使いやすいようにあれしておこう。
code:bash
echo -e '\n# HomeBrew\nexport PATH="/home/linuxbrew/.linuxbrew/bin:$PATH"' >> ~/.bash_profile
やったあとはターミナルを再起動するか exec $SHELL -l でロードし直しておこう。
Fish Shell をいれる
標準では bash が利用できるが、むちゃくちゃカスタマイズしなくてもある程度きれいに整っている fish を利用する。シンタックスが POSIX互換とかじゃないので 手になじまない場合はこのあとの操作は適当に読み替えてね。 code:bash
brew install fish
デフォルトシェルの切り替えには chsh を使いそうになるが、fish を素直にデフォルトにするとあれになることがあるので予防策として以下のような定義を .bash_profile の一番最後に定義しておく。MacOS の環境下でも似たような設定をしているが簡易的に下記のようになる。なお厳密にログインシェルかどうかの状態取ろうとしても WSL1 では効果がない。 code:bash
if $CHSHED != 1 ; then
export CHSHED=1
export SHELL="/home/linuxbrew/.linuxbrew/bin/fish"
exec $SHELL -l
fi
これでひとまずログインシェルが擬似的に fish になり、fish から bash を起動しても bash が素直に起動する。明示的に起動したbash での環境変数の多重定義を嫌う場合はよしなにすると良い。
このあとのツールの設定のたぐいは、環境変数の場合は .bash_profile に書いて、それ以外の fish に依存する部分は config.fish に書くことにしている。ひとまずグリーティングメッセージが出てくる仕様を無効化してしまおう
code:config.fish
# disable greetings
set fish_greeting
Starship をいれる
好みだが PS1 (プレイステーションじゃない方) をカスタムするのが楽になるので最近は Starship を入れている。 code:bash
brew install starship
Fish から使う場合は config.fish に下記のように追記する。(bash のときは bash に書き換える)
code:config.fish
# starship
eval (starship init fish)
このあと入れるLLのバージョンを拾ってくれる便利機能があるがこれが WSL1 だともたついてしまうので、 .config/starship.toml に必要な文無効化する定義を入れれば良い。WSL2 になるとこの辺が早くなるといいな。
code:starship.toml
disabled = true
disabled = true
ghq を入れる
Gitリポジトリの管理がしやすいように ghq を入れておく。
code:bash
brew install ghq
設定は .gitconfig に書くがこのようにしている。場所はどこでもいいが root を <任意の場所>/src にすると Go との相性が良くなる。
code:.gitconfig
root = ~/workspace/src
FZF をいれる
同様の仕組みに peco もあるが、レイアウトが好みなので fzf を入れる。 code:bash
brew install fzf
なお環境変数で表示をいじれるが個人的に好みなのはこの設定。
(MacOS 環境下では iTerm から使うことが多いので height は 50% にしてある) code:bash
export FZF_DEFAULT_OPTS='--height 75% --reverse --border'
ghq と FZF を連携する
config.fishこんな関数を用意するか、よしなにアレンジしてスクリプトにする。
先程設定した FZF の設定がいい感じに反映されるのがわかるはず。
code:config.fish
function repo
ghq list | fzf | read r && cd (ghq root)/$r
end
Anyenv をいれる
LL の環境を入れていくのにだいたい使われる ***env を滞りなくインストールしようとしたらだいたい出てくる anyenv ちゃんを入れておく。一応動作するが Anyenv を経由して LLのエンジンが起動するまで少し待たされる。(5~7秒程度)。おそらくWSL1のIO性能がここに影響しているのだろう。起動してしまえばあとはほとんど影響ない。 code:bash
brew install anyenv
インストール後には シェルの再起動を求められるのでよしなに。
fish の場合は config.fish に下記を追記する。Starship の読み込みよりも前のほうが良い。
code:config.fish
# anyenv
status --is-interactive; and source (anyenv init -|psub)
Nodenv をいれる
先ほど入れた anyenv から nodenv をインストールする nodeenv ではないことに注意。
code:bash
anyenv install nodenv
あとは Node.js をインストールすれば良い。
code:bash
nodenv install 13.2.0
nodenv global 13.2.0
nodenv exec npm install -g yarn
nodenv rehash
node -v
yarn -v
Go をいれる
基本的に最新版の Golang にしか興味がないので brew から go をインストールする。いつもどおり。
code:bash
brew install go
適当に GOPATH を設定するが、 ghq の root に設定したディレクトリの1つ上を設定しておくと何かと都合がいい。
code:bash
export GOPATH="$HOME/workspace"
export PATH="$GOPATH/bin:$PATH"
ちなみにGoのインストールに、goenv を使った場合は GOPATH の設定がこれではできないので、GOENV_DISABLE_GOPATH=1 を GOPATH の定義の前に定義しておく。
open コマンドを再現する
MacOS 使ってて便利なのが open コマンド。関連付けされてるアプリでファイルを開いたりディレクトリを開いたりできる。
Windows では explorer.exe に雑にファイルやフォルダを投げるとよしなに起動してくれるので alias を貼って使いやすくしておく。
code:config.fish
alias open explorer.exe
ちなみに bash から explorer.exe にカレントディレクトリを渡すと \\$wsl という仮想的なネットワークドライブを参照できるが、ここにファイルをポイポイ投げるとWSLにきちんと反映されるので便利。Windowsとの親和性が上がっていてすごく助かる。
/icons/hr.icon
ひとまずこれくらいでおしまい。
あとは .ssh の鍵を WSL 上に展開したりとか editorconfig の設定 を入れたりとかすると完成。
WSL1上で localhost に bind したアプリは Windows 上のブラウザからも参照できるので、IOが遅いことを除けばほぼ MacOS での体験を再現できる。
普段遣いのコツ
cmd から WSL1 を起動するのではなく VSCode の Remote WSL を起点にする。
いつも使うエディタがすぐそこにあるし、快適なターミナルがそこにあるので迷うことがない。
レンダリングも基本的に崩れたりしない。
Windows とファイルをやり取りするときは explorer.exe でフォルダを開いてファイルをぽいぽいする。
やらないほうがいいこと
WSL2 は別かもしれないが X Window 関係のアプリをどうこうするのは基本的にやめたほうが良さそうな雰囲気。
Electron でアプリを作りたいとなったら素直に Windows 上に環境を作ってやると間違いがないし早い。 あと高度にIOを求めるような用途には向かない。WSL2を待つかVMにするか Docker for Windows を使うことを検討すること。